Monitoring Beacons with FAROS 
Carl Luetzelschwab K9LA — October 2014 


The December 2013 column discussed getting more involved in radio than just making QSOs. It 
demonstrated a relatively easy way (with caveats, of course) to make elevation angle 
measurements of arriving signals. This month’s column discusses another example of an 
experiment that can be undertaken by most Amateurs. 


It uses the NCDXF/IARU beacons and associated software to see what’s happening with respect 
to propagation over a designated path, including the opportunity to compare actual propagation 
to predicted propagation. For the record, NCDXF is the Northern California DX Foundation and 
IARU is the International Amateur Radio Union. 


Information about the NCDXF/IARU beacons is at http://www.ncdxf.org/pages/beacons.html. 
There are 18 beacons around the world, and they transmit on 20m, 17m, 15m, 12m and 10m. 
Each beacon on each band transmits for 10 seconds. Thus in a three minute period, one can 
assess worldwide propagation on a given band. 


The software is the automatic Faros beacon monitor software offered by Alex Shovkopylas 
VE3NEA. Visit http://www.dxatlas.com/faros for details. This software continuously monitors 
the beacons, measures the SNR (signal-to-noise ratio), measures the delay (after proper 
calibration of your system), derives a QSB index of the signal strength and then presents the data 
in graphical format. Refer to the Faros documentation for proper set-up of your system and 
discussion of the various measured parameters. 


What results can you expect to see after everything is running and you’ve monitored a beacon 
and collected data? I'll use data from Tony Bombardiere K2MO to show some of the expected 
(and unexpected) results. 


Figure | is the result of K2MO monitoring the ZL6B beacon on 20m for the entire day on June 
14, 2014. This image also shows some of the Faros software options. For this entire 24-hour 
period, K2MO’s 5-element monoband 20m Yagi was pointed along the long path to ZL6B (a 
heading of 65 degrees). 


File View Help 
D 
AllBands | 14 18) 21) 24) 28 


4U1UN 
VEBAT 
WEWX 
KHEWO 
ZL6B 
VKBRBP 
JA2IGY 
RRSO 
VR2B 
4578 
ZS6DN 
BZ4B 
4XBTU 
OH2B 
C538 
LU4AA 


vali, wo tia fe th dai tt 
ae LT ee ere || calla || 


O Date 2014-06-14 4 | >| >1/M) Delay correction | 370ms — [dh 


rr. 


nH 


a 
a 
B 
= 
- 


1] 


Jina 


Figure 1 — ZL6B to K2MO on June 14, 2014 


The delay measurements (dark blue dots) are the top plot, with the delay axis in milliseconds 
(ms) on the right. The short path from K2MO to ZL6B is around 14,452 km, and the short path 
delay calculates to 48 milliseconds. The long path from K2MO to ZL6B is around 25,580 km, 
and the long path delay calculates to 85 milliseconds. Note that the correction factor for the delay 
in K2MO’s system is 370 milliseconds, which is mostly a delay through the internet to receive 
the beacon transmit timing pulse. 


The SNR data is the green vertical-line data in the middle plot, with its scale on the right (in dB). 
The QSB index data is the reddish vertical line data in the bottom plot, with its scale on the right 
in percent. 


Note that long path propagation begins around 2000 UTC and goes to about 0300 UTC on this 
day in June. Also note that short path propagation starts around 0300 UTC and goes to about 
1300 UTC. The short path SNR is actually higher than measured as it is off the back of K2MO’s 
5-element Yagi — K2MO says the front-to-back is something like 24 dB. 


Also note the delay times when propagation changes from long path to short path around 0300 
UTC. The intermediate values of delay suggest a non-great circle path - commonly referred to as 
a skewed path. From last month’s column, it would be interesting to understand why long path 
failed after 0300 UTC, why short began after 0300 UTC, and what possible skewed path filled in 
between long path and short path. 


A caveat is in order here. Before charging off on the tasks in the previous paragraph, it would be 
good to understand what the Faros software does when both long path and short path are 
simultaneously present. Both paths could be arriving into K2MO, and the question to ask is 
“does the Faros software get confused under this condition?” If you’ve ever heard a station 
coming in on both short path and long path at the same time, you’ll understand that it could be 
extremely tough to copy. 


Figure 2 is another set of data from K2MO. It shows the results of monitoring the ZS6DN 
beacon on June 15, 2014. The short path delay for this path calculates to 42 milliseconds. 
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Figure 2 — ZL6B to K2MO on June 15, 2014 
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There were two periods (0500-0700 UTC and 2300-0000 UTC) of decent short path propagation. 
But there were also two extremely brief openings around 1700 UTC and around 1930 UTC. 
These are a great example of the dynamic short-term nature of the ionosphere, and would cause 
wonder if you were “in the right place at the right time”. 


Another interesting result (but not shown) was a 3-day monitoring of the RR9O beacon in 
Novosibirsk, Russia. This is an over-the-pole path for K2MO, and as such we would expect 
geomagnetic field activity and polar cap absorption events to cause problems. Indeed, on two of 
the three days there is a short path opening between about 0900 UTC and 1500 UTC. But on the 
other day, there was no short path opening. A quick look at space weather (for example, at 
http://www.swpc.noaa.gov/today.html#satenv and http://www.swpc.noaa.gov/today.html#xray) 
showed an elevated K index on that day that was the likely culprit. 


Lastly, I mentioned earlier that the Faros software allowed comparing measured results to 
predicted results. K2MO had several of these comparison (again, not shown), and they were 
compared to W6ELProp predictions. This all comes out of the Faros software, so there’s no need 
to do any extra work. 


There you have it — a relatively easy way to study real-time ionospheric propagation. You 
certainly could generate a lot of data, but I suggest starting out simple with just monitoring one 
beacon on one band. As you gain experience, you could add more beacons or more bands — or 
both. As always with real-world experiments, pay attention to the details of your set-up to keep 
your observations and resulting conclusions valid. 


